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A client (3) and server (5) interposed by a connection manager (6) for impteraentmg cc^iununications protocols between a client (3) 
and server (5) in a transparent, application- wdeperKient. non-invasive fashion. The connection manager (6) comprises a client component (3) 
typically resident on the client machine (2) and a server component (5) typically resident on the server machine (4). The client component 
(3) accepts connection requests from client applications and sets up those co nne c ti on* in cooperation with the server component (5) of the 
connection manager. The connection manager (6) identifies the type of connection requested (e.g.. ftp. http. gss-http) based on such thing* 
as the content of the request and invokes methods specific to the type of connection requested. In this manner, the connection manager 
carries out the higher-level protocols, such as security protocols, for the collection m a way that is transparent to both the client (3) and 
server (5), 
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FIELD QP TUP imx/cut»i n 

The present invention relates to computer networks having enhanced and/or 
extended client/server communications. More particular*, the present .nvention is 
characterized by an application-dependent, obiect-onented connection manager for 
* processing client/server connections (communications sessions) between client 
computers and server computers. 

BACKGROUND qe t ^e iMVPMnnu 

Client/server communications between client computers and server computers 
.0 are commonly established by the interaction of an application program running on the 
client and a corresponding application program running on the server. The client/server 
model is the conventional mode, governing the transfer of data between application 
programs on a computer network. According to this mode., the high-level protocols for 
reading and writing data between a first computer (the client) and a second computer 
5 (the server) are embedded in the application software running on the client and server, 
respective*. Prior to the transfer of data, a communications session must be 
established over the network between the client and the server. 

Such a communication session is established according to a number of layers" 
of protocols. Among the lowest level protocols, physical connectivity between the client 
o machine and the server machine is established and maintained. For example, the 
Ethernet CSMA/CD protocol is a common data link layer protocol governing the orderly 
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transmission of packets of data between a client and server. Higher-level protocols, 
such as the TCP/IP and XNS transport layer protocols, govern the assembly of data 
into messages and the uniform addressing of various computers on the network Due 
to the established nature of protocols at these levels, much client software has these 
5 protocols "built-in" so that these protocols are automatically employed when the client 
software is run on a client or server machine on the network. 

StiW higher level protocols govern the interoperability of particular client/server 
applications such as file transfer, remote file access, electronic mail. etc. Examples of 
such applications include Internet-based applications, where use of a file 'transfer 
10 protocol permits the transfer of files from ftp server sites (ftp://xxx.)oa); a different 
protocol permits a client to browse documents in hypertext mark-up language (html) 
format at http server sites (http://xxx.xxx); and yet another protocol governs the 
establishment and maintenance of secure communications sessions between a client 
and server at gss-http sites (http://xxx.xxx:488). For these higher-level protocols, each 
is clienVserver application is typically specially adapted at the source code level to 
implement these protocols. In other words, the task of setting up a client/server 
communications session employing the desired protocol is typically accomplished by 
applicator-specific code developed by the application vendor for permitting the 
application program to be run on a client and communicate with a server on the network 
20 using higher-level protocols such as ftp. http. or gss-http. 
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Client for forwarding on to the Web browser. The Connect Client acts as a "proxy. " 
intercepting document requests from the Web browser and determining whether a 
secure document is sought. If the URL of the requested document contains a DCE 
name, the Connect Client uses DCE RPCs to forward the request to the Connect 
5 Server resident on the secure server. If the URL contains a non-secure address, the 
Connect Client forwards the request to the appropriate standard Web server using http 
In this way, the WebCrusader transparently performs the security functions of 
authentication, authorization and encryption between a dient application and a server 
using DCE. The software is strictly limited to the RPC protocol between client and 
10 server, however, and is not stream-based. 

What is needed is an application-independent client/server connection manager 
suitable for use with any higher-level protocol, such as ftp, http. DCE and gss-http 
without having to convert to RPC call sequences. It is desired that such a connection 
manager tansparently set up and manage both secure and non-secure client/server 
15 byte-stream sessions, yet inter-operate with each application only at the object code 
level. 

SUMMARY OF THE IMVEMTIOM 

According to a first aspect of the invention, there is provided a client machine 
:o and a server machine in a computer system, wherein the client and server include a 
connection manager for establishing communications sessions using higher-level 

5 



SNSOOCIO: <WO M04971A1> 



WO 98/04971 

PCT/US97/I22I4 



pro*** ,„c „ m . np. or gss ^. The aant ^ ^ ^ ^ 

CaPa6 " °' rUnmn9 3 ** - includ. , ^ ^ suw 

as a hard dl* <„« fw $twjn9 „, ^ , ppfcaUon; a procMMr ^ ^ ^ ^ 

application; and maana for handling input/output (I/O). 

Th. connect m an.g., ^ , ^ ^ ^ ^ 

Cam machina. and a MIV .r compel running on lhe MMf ^ ^ ^ 
co-Ponan,, o, th . „,,„,,., ^ ^ ^ ^ ^ 

b«w«n , cton, app^ and , ^ a p pljcaton . Th , dBnt ^ 

,MU "' 5 *"« « — <•» ^u M , .o „, up and man^ a 

- — IcaKon, seM10 „ ^ appfeatlon ^ ^ ^ ^ 

ara « * san,., ccnponan, o, *a conn^ m .„^. t*. cl(eM Mpec( 
and *. a , pect are ,„ ,„ pM m|TOr jmagM of ^ ^ ^ ^ 

lom«y „ an 0 , „* communions t^waen ,he cl»n. and tha , enw . 

I. will b. undaraood ma, ft. eonn^n inBW „ g „ ^ ^ ^ 

> =n,pon.n». =» b. run on a n«chin. «har ,n«, m. ^, macWne ^ g- 
** applied n™, o, th. „n» r machina «„„ ^ „. ssrv , r ^ 
For ..amp,.. ,„ , n^ort,*, ,„„ , nvlrenraen , , ^ a ^ 
appl**.* n»y b. m,^^ ^ , MpMle ^ ^ ^ 
™nagar. which n»y m«, .ppiy m . appropnat . fc ^ 

> connectan ba.w«n m. d«m ,„*««,„ and . diran| ^ .^^^ 



BNSOOCIO <W0 980497tAI> 



WO 98/04971 PCT/US97/m.4 



The connection manager handles requests from a dient application using an 
object-oriented approach to process (set up and manage) the communications session 
between the client application and the server application. The connection manager is 
"object-oriented* in that it uses various discriminators determinable from the client or 
5 server communication content (e.g.. protocol, dient or server address, data type, etc.) 
to evaluate which type of communications connection, or class, is called for By 
observing these discriminators, the connection manager can type" the object and call 
on the communications methods corresponding to that dass of connection when setting 
up the communications session and carrying out the communications protocols 

10 between the client and the server. 

According to a second aspect of the invention, the connection manager is 
application-independent. A variety of dient/server applications may be used with the 
connection manager, and these applications need not be adapted for use with the 
connection manager. The connection manager receives ordinary requests originated 

15 by either the dient or the server and uses the content of those requests to set up and 
manage a communications session between the dient and the server. Requests from a 
wide variety of applications and for a wide variety of daases of connections can be 
accommodated by the connection manager in this manner. 

According to a third asped of the invention, the connection manager maintains 

:o one or more adive "listener" objects that await requests for connections of particular 
types. When a connection is accepted on a particular listener, the connection manager 
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application at the source code level. 



BRIEF DgSCRtpjinn ? c THE DRAW/lf ^c 

FIG. 1A is a simple block diagram representation of a client/server connection 
1 5 manager according to the present invention. 

FIG, 1B is a block diagram of a client/server connection manager separated into 
its client and server components in a distributed computing environment. 

FIG. 2A is a functional design diagram of the dient component of a connection 
manager with active listener objects which determine when connections of vanous 
20 types are requested by a client application. 
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FIG. 2B is a functional design diagram showing a single listener object 
associated with a single class of methods for an http connection. 

FIG. 3A is a flow chart of the functioning of a client/server connection manager in 
the computer system according to the present invention. 
5 FIG. 3B is a more detailed textual outline of the now chart shown in FIG. 3A. 

FIG. 4A is a communications activity flow diagram showing the establishment of 
a communications session between a client and a server using only the client 
component of a connection manager. 

FIG. 4B is a textual outline of the communications activity shown in FIG. 4A. 
10 FIG. 5A is a communications activity flow diagram showing the establishment of 

a secure communications session between a client and a server using both the client 
component and a server component of a connection manager. 

FIG. 5B is a textual outline of the secure communications activity shown in FIG 

5A. 

15 

DETAILED DESCRIPTION Of TH E PREFERRED EMBODIMENT 
Referring now to the Figures, the invention in its simplest form is illustrated in 
FIG. 1A. wherein a client machine 2 and a server machine 4 are interposed by 
connection manager 6. Client machine 2 may have resident thereon one or more client 
:o applications 3, and these applications wHI typically interact with one or more server 
applications S to obtain data, files, graphics, etc. from the various servers. For 
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example, server machine 4 may be a server for one or more of ftp. http. or g 0 p her 
programs on the Internet, or it may be an electron* mail server or other server on a 
private network. The invention encompasses any type of client/server combination 
where such is interposed by a connection manager of the type described. 
* Connection manager 6 in its simplest form resides on client machine 2 and 

manages the connections between the various client applications 3 and their target 
server applications 5. Connection manager 6 sets up and manages these client/server 
connections using an object-oriented approach to determine, based on the type of 
connection sought by the client application 3 or the server application 5. the- appropriate 
■o class of communications methods to apply to the connection so that input/output (I/O) 
between the client and server is processed seamlessly and transparently. The object- 
oriented approach of connection manager 6 is described more fully below with 
reference to FIGS. 2A and 2B. 

Referring to FIG. 1B. connection manager 6 is shown to comprise client and 
1 5 server components where the client machine 2 and server machine 4 communicate at 
the application level over a network 8. Those components are designated connection 
manager/dient (CM7C) 10 and connection manager/server (CM/S) 12. respectively. 
CM/C 10 typically receives from the various client applications 3 certain connection 
requests destined for server applications 5. CM/C 10 types the object, or connection 
:o sought, according to the content of the request from client application 3. CM/C 10 and 
CM/S 12 then cooperate to establish the requested type of connection, applying the 
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appropriate higher level protocols through the collection of methods specific to the 
requested type of connection. For example, if client application 3 requests a secure 
(gss-http) Web connection, CM/C 10 and CM/S 12 invoke the communications methods 
associated with the gss-http class of connection; neither the client application 3 nor the 
s server application S may be aware that the gss-http protocols are being implemented by 
CM/C 10 and CM/S 12. 

Once a connection is established by the components of connection manager 6. 
I/O between client application 3 and server machine 4 is dispatched by CM/C 10 and 
CM/S 12 in a way that is transparent to the dient and server. CM/C 10 invokes the 
io communications methods associated with the particular type of connection established 
(e.g., Init, connect, read and write methods for an http-class connection), thereby to 
carry out the necessary protocol and giving the appearance that client application 3 is 
receiving I/O from the server application unaided by any other application or utility 
Thus, it can be seen that CM/C 10 interacts with client application 3 as if CM/C 10 were 
is in fact a server application, likewise, server application 5 interacts with CM/S 12 in the 
same way that server application 5 would ordinarily interact with a client application. . 
The connection is thus transparent to client application 3 and server application 5. 
which require no special knowledge that the components of connection manager 6 are 
interposed between the client and the server. 
:o Referring now to FIG. 2A. the establishment of dient/server connections by 

CM/C 10 is described. FIG. 2A representational^ shows a plurality of logical 
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CM/S 12 is preferably designed to mirror the operation of CM/C 10 and may be 
designed similarly to accept communications requests on behalf of server application 5 
and receive communications from the server. For simple connections such as http 
connection 18. where data is written to and from CM/C 10 without the need for 
5 enhanced protocols such as security protocols. CM/S 12 may not be active on the 
server side, and connection manager 6 may then be considered to comprise only CM/C 
10. which connects directly to server application 5. 

FIG. 2A shows the establishment of three different types of connections by CM/C 
10. although any type of connection can be accommodated by the present invention. 
io There is shown representational^ a logical, non-secure http connection 18 between a 
client application 3" and a server application 5 (not shown). This connection typifies the 
non-secure Internet communications between a client and server. Also shown are http 
connection 20 and secure gss-http connection 22. which employs the gss-http protocol. 
CM/C 10 cooperates with CM/S 12 (not shown) to set up each connection on 
is appropriate ports of server machine 4. For example, http connection 18 and http 
connection 20 are typically set up on non-secure ports 80, while secure gss-http • 
connection 22 is set up on secure server port 488 according to current standards. 

After the connections are established by CM/C 10 and CM/S 12. I/O between 
client application 3 and server application 5 is processed according to a collection of 
:o methods which are specific to the type of connection established. In FIG. 2A are shown 
connection objects 24, 26. and 28 which are associated with the methods for the http 
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class. h«p class, and gss-http Cass of connect™, .specie,. Typ.ca, methods 
include read, write, init and connect, although numerous methods may be ,nvoked 
depending on the connection type and the methods which are suitable for the particular 
connection type. The function^ of current methods is well known. For example, the 
s http read method is invoked any time input data from erther the client app.ication 3 or 
the server application 5 is available on an associated connection. The http init method 
is invoked as soon as a client connection is accepted by CM/C 10. And the http 
connect method is invoiced as soon as a server connection is established by either 
CM/C 10 or CM/S 12. 

The methods of FIG. 2A may be imp.emented in any of a variety of ways, 
including subroutines (both statically and dynamica.ly linked), executing ,cca, 
app.icat.ons. remote procedure ca.ls. Active-X and Java Statically and dyn.mie.Hy 
linked subroutines have proven to be an acceptabte means for implanting these 
methods. 

Referring now to FIG. 2B. there is shown a functional design diagram of CM/C 
10 for a single http<laas connection. Connection dass 31' defines the class of http 
methoctespecifictotr*^ object ir recedes a connecton 

request on http connection 1B. , n response, CM/C 10 accepts the connection request 
and creates connection object 24. which has pointers to the http read method 60', wr,te 
method 66'. connect method 64' and exception method 65. CM/C 10 also associates 
connection object 24 with the http methods of connection class 31' Event manager 14 
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makes calls to these methods to process the I/O on http connection 18. I/O events 
(e.g., reads, writes, and exceptions) may originate from either the client or the server 
Processing of these read and write events is handled by event manager 14 via process 
read routine 48 and process write routine 50, which make the appropriate calls to the 
5 methods associated with the connection object 

Referring now to FIG. 3A. there is shown a flow chart of the functioning of 
connection manager 6. which preferably has basic functions provided by an initialization 
routine 30, an event processing routine 32. and a quit routine 34. Initialization routine 
30 is executed once upon startup, and includes steps preliminary to establishing 

io client/server connections. In step 38. initializations specific to the platform on which 
connection manager 6 is installed are carried out The various program modules of 
connection manager 6 are initialized in step 38. The connection class definitions 
(reference numeral 31 in FIG. 2A) for connections to be managed by connection 
manager 6 are loaded in step 40. The appropriate methods for use with each 

is connection class are initialized in step 42 and the listener objects 18 (FIG. 2A) are 
created in this step. 

Event processing routine 32 processes I/O events, and these are preferably 
processed according to a process read step 48, a process write step 50. and a process 
exception step 52 for handling error conditions on the connection. In step 54. a read 
:o request is examined to determine whether it originated from the client or the server. If 
the read request originated from the client step 58 determines whether it is a request to 
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machine 4, with each component handling both read and write requests from the client 
and the server according to the steps above. 

When all connections are to be terminated, quit routine 34 carries out step 68 to 
delete any active connection objects (which closes all open connections) and step 70 to 
s deinitialize the classes of connections previously initialized in step 40. FIG. 38 shows 
in outline form the various steps of FIG. 3A. 

Example A: (-Insecure Web Connection fh , fl p) 
Referring to FIG. 4A, there is shown an activity flow diagram for a simpte. non- 
secure client/server connection which is set up and managed by connection manager 6. 
io In the example, an http class connection is established on the Internet; client 
application 3 is therefore presumed to be a Web browser and server machine 4 is 
presumed to be a Web server. Because no higher-level network protocols (such as 
security protocols) are required, connection manager 6 resides only on the client 
machine 2. Prior to the initiation of the activities shown in FIG. 4A, it is presumed that 
is connection manager 6 has been initialized and that at least one listener object 16 (FIG. 
2) of the http class is active. 

The operation of connection manager 6 for http-dass connections is now 
described. Typically, a user of client application 3 (Web browser) enters the Universal 
Resource Locator (URL), such as: 
20 http://server.com 

which identifies a Web site to be browsed (step 101). In response to the user entry of a 
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HTTP/1.0 200 OK[CR/LF] 
[CR/Lf] 

Hello World! 

5 This response is then read by connection manage'r 6 (step 112). Like the client 
application, the server s communication through connection manager 6 is transparent, 
and the server cannot discern that connection manager 6 is anything other than an http 
client 

Once connection manager 6 has received the response from the server, it writes 
io the response to the client application 3 (step 113). Client application 3 then reads the 
response and displays it to the user (step 114). Thereafter, connection manager 6 
closes the server connection in step 115. and subsequently client application 3 closes 
the connection with connection manager 6 in step 116. The steps associated with ail of 
the activities in this http example of FIG. 4A are shown in outline form in FIG. 4B 
1 5 The particular methods implementing the http class connection in Example A are 

outlined generally as follows: 

I. http_Classlnit 

A. CreateListener CO 

B. ConnObLSetlnitMethod(httpJnit) 
20 C. CreatAdmin? 

1. CreateListener 

2. ConnObj_SetlnrtMethod(http Inrt) 

II. httpjnrt 

A. ConnObj_SetReadMethod(http Read) 
25 B. ConnObLSetVVnteMethod(http~Wnte) 

C. (ConnectionManager/Server] ~ 

1. Ca!IMethod(gss Inrt) 

III. http_Delnrt 

IV. http_Connect 
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V. http_Read 

A. ReadRequestOrReadResponse? 
1 http_Read_Client_Request 

a) http.ReadJciientlnrt 

b) http_Read_Request 

c) rittp_Read_ClientHeaderAndBody 

(1) LocalOrRemote? 

(a) http_ProcessLocalURL 

(b) http_PTocea»RemoteURL 

i) SecureOrUnsecure? 

»l !!!? )nnectMetho < i (9«.Connect) 
• OpinRe^^ 

d) Http.Read.C^r^^ 
2. nttp_Read_Server_Response 

a) hltp_Read_Server»nit 

b) http_Read_Statu8 

c) http_Read~S«rv8rHead«rAndBody 

VI. http.Wnt* d> httP - Re8d - SerVerDone 

A. WrrteRequeatOrWriteReaponse? 

1 nttp_Wnte_CI»ntReque«t 

a) WrrteComplete? 

2 hnn vaw °2 S ^ ToRea ^ ; WriteRe S pon 3 e 
2. nttp_Wnte_ServerResponae 

a) WrrteComplete? 

VII. hdB.Excwon H) ConnObj_MarkForDeletion 

E " m °" "-n i n r fi fr TT mrnir Bun f i 

Ra^wrine, to FIG. 5A, them is shown an activity flow diagram for a secure gas. 
h* connect wh«h » .« „p ,„„ by aient ^ ^ 

C ° mPmem * C ° nnee,i0n »■ "<»•» CMC ,0 ,„d CM/S 12. As in Exampie 

A. diem aopil-to 1 » pr^rr*. to be a Web browser end server machine 4 i, 
presumed to be a Web sen*r. Prior to the mm, of th. shown in FIG. 5A. it 
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is presumed that CM/C 10 and CM/S 12 have been initialized and that at least one 
listener object 16 (FIG. 2A) of the http class is active on each of CM/C 10 and CM/S 12. 

The operation of CM/C 10 and CM/S 12 for secure gss-http connections is now 
described. At the outset, the user of client application 3 (Web browser) gives an 
indication in step 201 that he desires secure communications with a server, m 
response, client application 3 attempts to open a connection with CM/C 10 (step 202) 
and CM/C 10 accepts the connection (step 203). The client may then write a request to 
CM/C 10. such as: 

POST http://sefver.com;4a8/cgl-bin/foo HTTP/1 0(CR/LF] 
Content-length: 17 

tCR/LFJ**^* ^ , ' C ^^" w ^* forT ^ unencoded ^ CR/LF l 
name=John%20Smrth 

which includes a request line, header lines, and a user ID. CM/C 10 invokes the read 
method to read this request in step 205. 

The http read method observes the content of the request and determines that a 
gss-http secure connection is desired. Thus, the gss connect method will be set as the 
connect method associated with connection object 24 in FIG. 2B.- Next, the http read 
method opens a connection to the server (steps 206-208). CM/C 10 then cooperates 
20 with CM/S 12 to establish a connection by invoking the connection object s connect 
method (in this case, gss_Connect). which performs security context negotiation prior to 
the transfer of any secure data (steps 209-216). The server application 5 (Web server) 
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recent no requests and ta.es no part in the connection set-up until after CM/C 10 and 
CM/S 12 have successfully negotiated the secure connection. 

Upon completion of the security context negotiation between CM/C 10 and CM/S 
12. http write methods including security protocol are invoked by CM/C 10 to send the 
s. client request secure* to CM/S 12. Operating in mirror image fashton. CM/S 12 reads 
the client request in step ail Thereafter, in steps 219 through 225. CM/S 12 interacts 
with server application 3 to open a connect™ to the secer. send the client request to 
the server, and read the server response in a manner analogous to the interact™ 
between connection manager and server application 5 in steps 106-1 12 in Example a 
io above. The sample response written to CM/S 12 in FIG. SA is: 

HTTP/1 .0 200 OK [CR/LFJ 
ICR/LF] 

Hello John Smith! 

"J Now that the read and write methods invoiced by CM/C 10 and CM/S 12 provide for a 
secure connection, the server response may be securely written to and read by CM/C 
10 (steps 226 and 227) before CM/S 12 doses the server connection (step 228). After 
writing the reaponae to the client (step 229) for display to the user (step 230). the 
remainder of the connection, are then closed, first by CM/C 10 (step 231). then by 

» C*m application 3 (step 232). Thus. * can be seen from the example that the client 
and sender components of connect™ manager 6 established a secure gss-http 
connection between the diem and server by interacting with diem and server in a way 
that transparently mimics direct interaction between dient and server. 
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The particular methods implementing the gss class connection in Example B are 
outlined generally as follows: 

I. gss_Classlnit 

II. gssjnit 

5 A. ConnObLSaveCurrentMethods 

B. ConnOt>LSetReadMethod(gss Read) 

III. gss_Delnit 

IV. gss^Connect 

A. gss Inrt 
io IV. gss_Read 

A. [ConnectionManager/Client] 
1. gss_ReadJnit 

a) gss.AcquireAndFlushToken 
2 gss_Read_Token 

a) gss_Read_TokenHeader 

b) gss_Read_TokenBytes 

c) gss_AcquireAndFlushToken 

d) NegotiationComplete? 

(1 ) SetSocketParametersForTransparentEncrypt/Decrypt 

3. gss_Read_FirstEnaypted 

4. gss_Read_Done 

a) ConnObj_RestoreCurrentMethods 
B [ConnectionManager/Server] 

1. gss.ReadJnit 

2. gss_Read_Token 

a) gss_Read_TokenHeader 

b) gss_Read_TokenBytes 

c) gss_AcquireAndFlushToken 

d) NegotiationComplete? 

(1 ) SetSocketParametersForTransparentEncrypt/Decrypt 

(2) ConnObLSetWlriteMethod(gss Write) 

3. gss Read Done 

VI. gss_Write 

A. [ConnectionManager/Client] 

B. [ConnectionManager/Server] 

1. BufferAcknowtedgement 

2. WriteComplete? 
a) ConnObj_RestoreCurrentMethods 

VII. gss_Exception 
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CLAIMS 

We claim: 

1 A computer system providing enhanced communications between a client 
application and a server application, comprising: 

a client machine running said client application; 

a connection manager interoperable with said client application to: 

(a) receive from said client application a connection request for a 
specific type of connection; 

(b) identify the type of connection requested from a 
plurality of connection types; and 

(c) invoke methods for the type of connection requested, thereby 
establishing a connection between said client application and said 
server application. 

2. A method of enhancing communications between a client application and a 
server application in a client/server computing environment comprising the steps of: 

receiving from said client application a connection request for a 

specific type of connection, said connection request including a body; 

identifying the type of connection requested from a plurality of connection types; 

invoking methods for the type of connection requested; and 

writing said body of the connection request to said server application. 
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